Skip to content

Conversation

@tomwilkie
Copy link
Contributor

This is done inspired by a 'hack' in the bigtable client, where they use a resolver to return N copies of the same address. This is a little more generic.

Hope is this will help combat some of the very high tail latencies we see for distributor pushes.

Signed-off-by: Tom Wilkie [email protected]

gouthamve and others added 5 commits January 4, 2019 17:21
This is done inspired by a 'hack' in the bigtable client, where they use a resolver to return N copies of the same address.  This is a little more generic.

Hope is this will help combat some of the very high tail latencies we see for distributor pushes.

Signed-off-by: Tom Wilkie <[email protected]>
Signed-off-by: Tom Wilkie <[email protected]>
This is becuase we don't want to use it for the Bigtable client, and we don't want to override their existing hack.

Signed-off-by: Tom Wilkie <[email protected]>
@tomwilkie
Copy link
Contributor Author

Having testing this, I've not seen a big improvement - and arguable no improvement at all. Will close, not worth the extra complexity.

@tomwilkie tomwilkie closed this Jan 16, 2019
@bboreham
Copy link
Contributor

bboreham commented Mar 3, 2019

Wondering if the bigtable idea relates to this issue: golang/go#27044 which is addressed in Go 1.12.

gRPC connections are similar to, but not the same as, http/2 connections.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants